home *** CD-ROM | disk | FTP | other *** search
/ Collection of Tools & Utilities / Collection of Tools and Utilities.iso / dskut / filed39a.zip / src / notes.os2 < prev    next >
Text File  |  1993-04-11  |  19KB  |  579 lines
  1. This file, NOTES.OS2, contains various messages and remarks on the OS/2 port,
  2. and some magicfile suggestions by John Adams and Gisbert W. Selke. The email
  3. messages have been edited slightly for brevity and clarity.
  4.  
  5. General notes:
  6. 1. Versions were compiled with Microsoft C 6.00A and EMX/gcc 0.8f. 
  7.  
  8. 2. Some of the original code assumed 32-bit integers. The magic structure
  9. was changed in order to reduce the memory requirement. EMX and MSC changes
  10. can be found by searching for OS2, EMX, and MSC. Bugs in the original
  11. sources can be found by searching for the word "bugfix".
  12.  
  13. 3. MSC stat() is broken on directory names--see Stat() in fsmagic.c.
  14. MSC utime() works as documented, but is still broken.
  15.  
  16. 4. Use spawn instead of fork in EMX/gcc. No pipes in MSDOS; use tempfil.
  17.  
  18. 5. Add apptype.c, which uses DosQ[uery]AppType to determine the type
  19. of executable. If apptype.c has the filename, then apptype can determine
  20. the file type (see apptype.c for one special bug). 
  21.  
  22. However, when the program is reading from stdin (or from a pipe due to "-z"
  23. unwinding), then apptype only sees the part of the file provided by the
  24. program (HOWMANY bytes).  In this case, DosQ[uery]AppType may not be able to
  25. distinguish, for example, a DOS exe from an OS/2 exe.
  26.  
  27. 6. The usual problems with binary vs text files, EOL, and directory 
  28. separators must be handled. strtol in EMX and MSC libs returns LONG_MAX
  29. on overflow--use strtoul with sign check or the supplied localsrc/strtol.c
  30.  
  31.  
  32. =============================================================================
  33.  
  34. To: Darrel R Hankerson <hankedr@mail.auburn.edu>
  35. Cc: darwin@cs.toronto.edu
  36. Subject: Re: file ported to OS/2 1.x--2.x 
  37. In-Reply-To: Your message of Mon, 05 Apr 93 07:39:25 -0500.
  38. Date:     Mon, 5 Apr 1993 10:51:49 -0400
  39. From: ian@sq.com
  40.  
  41. On Mon, 5 Apr 1993 07:39:25 -0400  Darrel R Hankerson wrote:
  42.  
  43. >I have nearly finished a port of [file v3 patchlevel5]
  44. >for OS/2 1.x--2.x.
  45. Glad to see it's been made available for OS/2. Thanks!
  46.  
  47. >The main changes are:
  48. > 1. Change fork() to spawn() (needed for 1.x).
  49. > 2. Add API calls to determine executable type.
  50. > 3. malloc() the magic->desc to reduce memory usage (needed for 1.x).
  51.  
  52. Yes, I'd like to get the source changes back. HOWEVER time has not
  53. stood still; I am now distributing version 3.9, and would rather not
  54. have version 3.[5] circulating. If you have your diffs as patch files,
  55. would it be possible for you to get the lastest (by ftp from
  56. ftp.cs.toronto.edu in /pub/darwin/file), apply and test them again, and
  57. then send the new version both to me (for baseline source) and also:
  58.  
  59. >... upload this as "file3[9].zip" (with context diff's and suitable
  60. >documentation) to the main OS/2 sites...
  61. Then we'd all be distributing the same version...
  62.  
  63. [The current version given in] patchlevel.h now says:
  64.  #define FILE_VERSION_MAJOR    3
  65.  #define patchlevel        9
  66.  
  67. Actually, when I get your OS/2 changes in, it'll be 3.10!
  68.  
  69.  
  70. You also mentioned some
  71. >Minor magic-file problems:
  72. which I'll track down.
  73.  
  74. >The porting was made easier by the excellent form of the sources. Your
  75. >program is a fine piece of work.
  76.  
  77. Thanks for the feedback!
  78.  
  79. Ian Darwin        Free Fine File(1) FTPable From Ftp.cs.toronto.edu
  80. ian@sq.com        cd /pub/darwin/file; get README.FTP -; binary;
  81. Toronto, Canada        mget dist.*
  82.  
  83.  
  84. =============================================================================
  85.  
  86. Date: Tue, 6 Apr 93 09:20:50 CDT
  87. From: Darrel R Hankerson <hankedr>
  88. To: ian@sq.com
  89. Cc: darwin@cs.toronto.edu
  90. In-Reply-To: ian@sq.com's message of Mon, 5 Apr 1993 10:51:49 -0400 <m0nfsWp-0003bFC@sq.com>
  91. Subject: file ported to OS/2 1.x--2.x 
  92.  
  93. [...] I do see a few new buglets in 3.9:
  94.  
  95. 1. In ascmagic.c, you've changed the check for the esc. But there are only 
  96. nbytes of valid data, right?
  97.  
  98. #ifdef OS2                      /* bugfix, not OS/2 specific */
  99.         s = (unsigned char*) memcpy(nbuf, buf, nbytes);
  100.         has_escapes = (memchr(s, '\033', nbytes) != NULL);
  101. #else
  102.         s = (unsigned char*) memcpy(nbuf, buf, HOWMANY);
  103.         has_escapes = (memchr(s, '\033', HOWMANY) != NULL);
  104. #endif
  105.  
  106. This reminds me of another question: In compress.c, would it make more
  107. sense to always read HOMANY bytes from the pipe (as uncompress will give back
  108. more bytes than the orig buffer)? 
  109.  
  110.  
  111. 2. print.c has not been updated to include the additional typ's:
  112.  
  113. #ifdef OS2              /* bugfix, not OS/2 specific */
  114.                 (m->type >= 0 && m->type < sizeof(typ) ?
  115. #else
  116.                 (m->type >= 0 && m->type < 7 ?
  117. #endif
  118.  
  119. You will see the bug if you try "file -c"
  120.  
  121.  
  122. I have working 32-bit OS/2, 16-bit OS/2, and MSDOS versions. I've
  123. added the API calls (in OS/2 versions) to determine the executable
  124. type (can't do this with magic entries).
  125.  
  126. Notes:
  127. 1. OS/2 1.x can't fork()--added code to use pipes and spawn.
  128.  
  129. 2. OS/2 2.x doesn't really like to fork; do spawn.
  130.  
  131. 3. MSDOS can't pipe; added tmpnam code.
  132.  
  133. 4. The 16-bit versions require some changes:
  134.    (a) a few int's need to be unsigned
  135.    (b) a few "%d" in printf need to be "%ld"
  136.    (c) change magic->desc to a pointer and malloc as needed. We need the
  137.        room. More changes here are probably desired, as the current magic
  138.        file has over 900 valid entries and MAXMAGIS=1000 is near the max for
  139.        the 16-bit version. I did have some problems changing 
  140.        mag->value.s to pointer when I played with 3.5. This would give more
  141.        room, but I have not modified 3.9 in this area.
  142.   
  143. 5. OS/2 and MSDOS programs need to handle the "traditional" EOL "\r\n" in 
  144. addition to "\n".  A minor change to softmagic.c (in 2 places) is needed.
  145. As an example, 
  146.  
  147. #ifdef OS2                              /* handle both "\r\n" and "\n" */
  148.                 (void) printf_eol(m->desc, p->s);
  149. #else
  150.                 if ((rt=strchr(p->s, '\n')) != NULL)
  151.                         *rt = '\0';
  152.                 (void) printf(m->desc, p->s);
  153.                 if (rt)
  154.                         *rt = '\n';
  155. #endif
  156.  
  157. printf_eol is suitably defined. Without this change, the printout will
  158. be incorrect for the tst files c.misc*.
  159.  
  160.  
  161. 6. OS/2 and MSDOS programs need to handle both '/' and '\\' as directory
  162. separators. Some minor changes are required. MSC stat() is partially broken
  163. on dir names, minor change added. 
  164.  
  165. --Darrel Hankerson hankedr@mail.auburn.edu or hank@ducvax.auburn.edu
  166.  
  167.  
  168. =============================================================================
  169.  
  170. Date: Sat, 27 Mar 93 22:36:16 CST
  171. From: Darrel R Hankerson <hankedr>
  172. To: mattes@iema.e-technik.uni-stuttgart.de
  173. Subject: How to recognise 16-bit apps
  174.  
  175. DH said:
  176. >> Proposal: Maybe we need a working "file" program with a flexible approach
  177. >> to magic entries. Mattes' apptype could be part of this project.
  178.  
  179. EM said:
  180. > I can provide the code required for identifying the emx version (and
  181. > whether a program is an emx program or isn't), if you need it.  A
  182. > "file"-like approach cannot be used for identifying the type of an
  183. > .exe file -- the NE and LX headers can be almost anywhere.
  184.  
  185. I would like to add the code you mention. I also plan to add the "apptype"
  186. code. 
  187.  
  188. 1. Do you have any suggestions on the way the output should look?
  189.  
  190. 2. How can I identify EMX .o and .obj files?
  191.  
  192. 3. Where can I get an extensive list of magic entries?
  193.  
  194. --Darrel Hankerson hankedr@mail.auburn.edu or hank@ducvax.auburn.edu
  195.  
  196.  
  197. =============================================================================
  198.  
  199. From: Eberhard Mattes <mattes@azu.informatik.uni-stuttgart.de>
  200. Date: Fri, 2 Apr 93 14:03:24 +0200
  201. To: hankedr@mail.auburn.edu
  202. In-Reply-To: Darrel R Hankerson's message of Sat, 27 Mar 93 22:36:16 CST <9303280436.AA04246@ducserv>
  203. Subject: How to recognise 16-bit apps
  204.  
  205. > 1. Do you have any suggestions on the way the output should look?
  206.  
  207. It should be `machine readable'.
  208.  
  209. > 2. How can I identify EMX .o and .obj files?
  210.  
  211. Use the standard i386 Unix magic entry for .o files (0407).  .obj
  212. files start with a THEADR record (a byte of 0x80, followed by two
  213. bytes indicating the length of the record).
  214.  
  215. > 3. Where can I get an extensive list of mag